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Description 

[0001] The present invention relates to a arbiter and a method of arbitration and in particular, but not exclusively to 
an arbiter for requests lor obtaining nnemory access. 

s [0002] Hardware memoiy arbiters of various different types are known. The simplest type is a fixed priority system. 
In this system, each device requesting access to the memory is allocated a priority. The device having the highest 
allocated priority and which is requesting access will always win access to the memory. Whilst fixed priority arbiters 
ensure that it is always known which device wins access to the memory, it can result In a device with a low priority 
being starved of access to the memory. In other words, low priority devices may, in certain circumstances, be prevented 

10 from having access to the memory. However, this scheme does allow those devices which require frequent access to 
the memory to have a greater share of the available accesses. 

[0003] A second type of memory arbiter is a rotating priority or round robin arbiter. This is illustrated in Figure 1. A, 
B C and D represent devices requesting access to the mernory. The device with the current highest priority Is at the 
top of the list whilst the device with the current lowest priority is at the bottom of the device. An X next to the device 
indicates that the device Is requesting access to the memory. Initially, as devk:e A has the highest priority and is re- 
questing access to the memory, it Is granted access to the memory. This is illustrated in Figure la. 
[0004J Subsequently, as illustrated in Figure 1b, device A Is assigned the lowest priority and device B now has the 
highest priority. As device B is requesting access to the memory, and it has the highest priority, It is granted access to 
the memory. Next, as shown in Figure 1 c, device B is given the lowest priority and device C now has the highest priority 
20 As device C has requested access to the memory it wins access to the memory. 

[0005] Likewise, in Figure Id, device D has the highest priority and has requested access to the memory and thus 
wins access to the memory. Device C has the lowest priority. 

[0006] However, in Figure te, device A has the highest priority but has not requested access to the memory. Accord- 
ingly, the device having the highest priority and which has requested access to the memory wins. In the case of Figure 
2S lo that is device 8. 

[0007] Device 8 is then assigned the lowest priority but device A maintains its highest priority This is shown in Figure 
If. However, device C is the highest priority device requesting access and thus wins the arbitration. 
[0008] This system has the advantage that each devk;e has an equal chance of winning over time. However, this 
does not allow for one device to have a greater proportion of the available bandwidth. This means that the operation 

30 of the system can be slowed unnecessarily 

[0009] More complex schemes have been proposed which, lor example, consider the last N accesses/cycles and 
determine the winner for a current access or cycle taking into account the number of past wins of each device as well 
as its priority. However, these systems require a large amount of hardware to implement. This may mean that the arbiter 
may take up a large area on a integrated circuit, which is undesirable as this slows down the time taken to make 

35 arbitration decisions. This latter disadvantage can result in delays being introduced into the system which may offset 
any advantage obtained from the particular use of the complex arbitration scheme. 

[0010] Accordingly, it is an aim of embodiments of the present invention to provide an arbiter and a niethod of arbi- 
tration which overcomes the disadvantages of the various known schemes. 

[001 1] According to one aspect of the present invention, there is provided an arbiter for arbitrating between a plurality 
^0 of requests from a plurality of requesters, said arbiter being arranged to assign an order of priority of said requesters, 
the requester having the highest priority and which has made a request winning the arbitration, wherein the arbiter 
determines a new priority for said winning requester, said winner being given a priority different from the lowest priority. 
[001 2] Arbiters embodying the present invention can be implemented simply and yet provide a degree of complexity 
to the arbitration. 

4^ [0013] Preferably, the arbiter is arranged to assign relegation Information to each of the requesters, the relegation 
information determining the priority of a winner of the arbitration after the winner has won an arbitration. The relegation 
Information may comprise an arbitration value which defines the number of positions by which the winner of the arbi- 
tration is relegated. Alternatively, the relegation information may take the form of a relegation positbn which defines 
the position to which the winner of the arbitration is relegated. 

50 [0014] The relegation information can be changed during use of the arbiter. In other words, the arbiter can be con- 
figured during use. 

[0015] Preferably, the arbiter has a list of requesters, the list defining the priority of the requesters, wherein the list 
is arranged to include at least one requester in at least two different positions in the list. The list is preferably longer 
than the number of requesters. The winner of an arbitration can either go to the end of the list or be inserted into a 
55 position within the list. 

[0016] It should be appreciated that not alt winners will be given a priority different from the lowest priority. In some 
embodiments of the present invention, at least one winner may be given a priority different from the lowest priority. 
[0017] According lo a second aspect of the present invention, there is provided an arbiter for arbitrating between a 
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requests from a plurality of requesters, said arbiter being arranged to assign an order of priority to said requesters and 
relegation information to each of said requesters, the relegation information determining the priority of a winner of said 
arbitration after the winner has won an arbitration. 

[0018] According to a third aspect of the present invention there is provided an arbiter for arbitrating between a 
s plurality of requests from a plurality of requesters, said arbiter having a list of requesters, at least some of said requesters 
making requests, the list defining the priority of said requesters, wherein said list is arranged to include at least one 
requester in at least two different positions in said list. 

[0019] In this example, the length of the list may be changed during use of the arbiter The winner of an arbitration 

may be sent to the end of the list or may be inserted at a given position within the list. 
10 [0020] According to a fourth aspect of the present invention, there Is provided an arbiter for arbitrating between a 

plurality of requests from a plurality of requesters, said arbiter assigning a priority to each of said requesters, the priority 

assigned to each requester detennining the frequency with which each requester wins an arbitration, wherein said 

arbiter is configurable to provide to the required priority for each requester 

[0021] The arbiter may be configured prior to use and/or be alterable during use. 
IS [0022] The arbiter may arbitrate between requests from requesters requesting access to a memory. The requester 

can be a device or a channel. 

[0023] The arbiter may be arranged to consider only some of the requesters when arbitrating between the requesters, 
the considered requesters having the highest priority. 

[0024] It should be appreciated that the various aspects described hereinbefore can be used in conjunction with 
20 each other. 

[0025] According to a still further aspect of the present invention, there is provided a method of arbitrating between 
a plurality of requests from a plurality of requesters, said method comprising assigning an order of priority to the re- 
questers, determining which requester has the highest priority and which has made a request, said requester winning 
the arbitration, determining a new priority for the winning requester, the new priority being different from the lowest 
25 priority. 

[0026] For a better understanding of the present invention and as to how the same may be carried Into effect, refer- 
ence will now be made by way of example to the accompanying drawings in which:- 

Flgure 1 shows a known rotating priority arbiter; 
30 Figure 2 shows a arbiter embodying the present Invention; 

Figure 3 shows the implementation of the arbiter of the first embodiment. 
Figure 4 shows an example of the implementation of the priority list of Figure 3; 
Figure 5 illustrates a portion of a transport stream; 

Figure 6 illustrates in block schematic fonn a programmable transport interface; and 
35 Figure 7 illustrates in more detail the interconnection of the DMA controller of Figure 6. 

[0027] Reference is now made to Figure 2 which shows an arbiter embodying the present invention. In particular, 
Figures 2a to 2g show seven successive arbitration decisions. Initially, device A has the highest priority and device D 
has the towest priority with devices B and C having the second and third highest priorities respectively. Asiwith Figure 
40 1 , an X Indicates that access is being requested. As device A has the highest priority and is requesting access, in 
Figure 2a, device A will win the arbitration. 

[0028] However, as shown in Figure 2b, device 2A is not assigned the lowest priority but instead is assigned the 
second highest priority and is inserted between device B and device C in the list of priority. As device B now has the 
highest priority and has requested access, It will win the arbitration. 
45 [0029] N ext. device B Is moved to the bottom of the list and thus has the lowest priority, as shown in Figure 2c. Device 
A thus has the highest priority and as it is requesting access, it wins the arbitration. 

[0030] As illustrated in Figure 2d, device A is again given the second highest priority and is inserted in the list between 
devices C and D. As device C has the highest priority and has requested access, it wins the arbitration. 
[0031] In Figure 2e device A again wins the arbitration and, as illustrated in Figure 2f is inserted into the list with the 
so second highest priority. Device D wins the arbitration and, as shown in Figure 2g is assigned the lowest priority Device 
A again has the highest priority and as it requesting access, it wins the arbitration. 

[0032] in the example shown in Figure 2, if all of the devices continually make requests, device A will win 50% of its 
requests and the other devices B, C and D will share the other 50% of accesses. 

[0033] The principal illustrated in relation to Figure 2 can be extended so as to control the amount by which each 
55 device is relegated in terms of its priority when it wins an arbitration. In the example shown, device A is relegated by 
one position whilst devices B, C and D are all relegated by three positions if they win the arbitration. 
[0034] By programming the value by which each device is relegated after winning an arbitration, the arbiter can be 
configured to operate in the most appropriate manner taking into account the nature of the devices. If all the relegation 
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values are zero, this means that any winner wilt not move in the list and a fixed priority arbiter is thus established. Each 
device can have the same or different programming values between zero (where the device winning the arbitration 
stays in the same position) and a value of L-1 where L is the number of devices in the list. 
[0035] Reference is made to table 1 which shows how an arbiter can deal with four devices. 



Table 1 
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[0036] In the first exannple given in the table, the relegation value, that is the position to which a device is relegated 
if it wins arbitration, lor each of devices A, B, C and D is zero. In other words, the arbiter acts as a fixed priority arbiter 
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For example, if device A has the highest priority and it always has a request, then device A will always win. In this 
example as well as the following examples, the initial priority is considered to be devices A, B, C and then device D. 
As shown in this example, where a contender has zero relegation value, it will lock out all other devices if it has a higher 
priority and is always requesting. This of course can lead to stan^ation where devices are prevented from accessing 
5 the memory. Fixed priorities may be desirable in certain scenarios but this always has to be weighed up against the 
risk of starvation. 

[0037] However, in a dynamically programmable system, a device at risk of starvation could have a time out on its 
request which triggers an interrupt to the CPU requesting that it reprogrammes the relegation value to something more 
favourable. 

10 [0038] As will be appreciated, the arbiter can be reprogrammed by the CPU during the operation o1 the device of 
which the arbiter forms a part or may be fixed in its operation by its initially programming. 

[0039] Reference is made to the second example where the device with the highest priority initially has a relegation 
value of zero. The other three devices B, 0 and D have relegation values of 3 which means that they rotate. If device 
A makes requests on every cycle, It will win 100% of the time with devices B. C and D being starved of access. 
IS [0040] However, consider the third example in which the first device, device A has a relegation value of 1 and the 
three remaining devices have a relegation value of 3. Device A will get 50% of the accesses with the remaining 50% 
shared amongst the remaining three devices. 

[0041] The fourth example Is similar to the third example except that the first device, device A has a relegation value 
of 2. This means that the first device, device A. will win the artDitratlon a 1/3 of the time. The remaining 2/3 of the time, 
20 the remaining three devices will win the same amount of access, i.e. around 22%' of the accesses. 

[0042] In the fifth example, device A has a relegation value of 1 , device B has relegation value of 2 whilst devices C 
and D have a relegation value of 3. A will win 50% of the time. Device B will win 25% of the time whilst devices C and 
D will win 12^/^% of the time. 

[0043] In the next example, device A and device 6 both have relegation values of 2 whilst devices C and D have a 
2S relegation value of 3. /Accordingly, devices A and B will each win 1/3 of the time. However, devices C and D will only 
win 1/6 of the lime. 

[0044] Finally, If all the relegation values are 3, a rotating priority arbiter is obtained where each device has an equal 
chance of winning access. 

[0045] In practice, not all of the devices will request access all of the time. For example if devices A to C had a 
30 relegation value of 2 and device D had a relegation value of 3, device D would be stan/ed of access if all devices were 
requesting access alt the time. If this is not the case, then device D will still get access to the device relatively frequently 
[0046] The nature of the accesses may be taken into consideration when considering the initial ordering of the priority 
list. A device at the top of the list but with a higher relegation value will not be at the top of the list once it has made its 
first request. This may be used to advantage, if the behaviour of the device is different straight after reset or alternatively 
35 this allows low priority tasks the opportunity to win an artDitration. It is of course apparent that a device with a zero " 
relegation value will never go back down the list once it has reached the top and will always have the highest priority 
[0047] As mentioned hereinbefore, the arbiter may have the same configuration which Is pre-programmed. Alterna- 
tively, the arbiter may have Its programming changed during operation of the integrated circuit with which it forms a 
part by, for example, the CPU. 
40 [0048] A further embodiment of the present Invention will now be described with reference to table 2. 
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[0049] In this embodiment, the list of requesters or devices has more slots than the total number of requesters. This 
means that some devices may be in the list more than once. In the examples, there are four requesters or devices A 

35 to D. The list Is 9 deep with the highest priority on the left and the lowest priority on the right. In each case the device 
which wins the arbitration goes to the end of the list. Initially, A is at the top of the list and is requesting and therefore 
wins the arbitration. A is then sent to the end of the list (see the second line of the table) and B Is now at the beginning 
of the list. B has the highest priority and as it is requesting wins the arbitration and is sent to the end of the list as can 
be shown from the third row of the table. 

40 [0050] Device C is now at the top of the list and as it is requesting, wins the arbitration and thus goes to the end of 
the list as shown In row 4 of the table. Device A Is now at the top of the list but not requesting. Accordingly, device B 
wins the arbitration and goes to the end of the list as shown in row 5 of the table. 

[0051] In the example shown in relation to table 2, the winners of the arbitration are always sent to the end of the 
list. However, this is not necessarily the case and the winner of the arbitration can be sent to different locations in the 

45 list depending on the Identity of the device, as described in relation to the first embodiment. 

[0052] The amount of logic used to look at such long chains could, for example, be reduced by only looking at the 
top of the list, perhaps the top four or even three items of the list. This technique can also be used where the list is 
only as long as the number of requesters. This may lead to the disadvantage that lower priority requesters may miss 
their chance if they are outside the checked window when they make their requests. However, in certain situations, If 

so the other requesters are not requesting anyway, there should be an opportunity for a lower priority requester to obtain 
access at a later date. 

[0053] In an alternative embodiment of the present invention, the relegation amount, the position of a device in a list 
and even the length of the list may be calculated depending on a factor of the system. This factor could be activity of 
the system, status of the system: mode of the system, a factor of the device or the like. The length of the list may also 
55 be programmable. For example, the list may be pre-programmed so as to always have a predetermined length. How- 
ever, the arbiter can be controlled during its operation to change the length of its list. 
[0054] The first and second embodiments can be used in conjunction with one another 

[0055] Reference is made to Figure 3 which shows how the first embodiment of the present invention can be imple- 
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mented. 

[0056] The priority list 2 is implemented as four two bit registers 6a, 6b, 6c and 6d. These registers 6a to 6d are 
connected together to allow shifting up, relegation by a programmable amount and programming by an external device 
such as a CPU. Each device is assigned a two bit number which is used to represent that device. The first register 6a 

s stores the identity of the device with the highest priority whilst the last register 6d stores the identity of the device with 
the lowest priority. The second and third registers 6b and 6c store the identity of the devices with the intermediate priority 
[0057] The relegation values are also stored in four two bit registers 8a to 8d. Each register stores the relegation 
value RV for one of the devices. In the case of the first embodiment, the maximum relegation value is 3 (represented 
by 11 in binary form). In other words the relegation value RV can have any value from 0 to 3. 

10 [0058] Each register 6a to 6d controls a respective 4 to 1 multiplexer 1 0a to 1 0d. Each of the multiplexers 1 0 receive 
an input from each of the requesters or devices. The first multiplexer 10a is controlled by the first register 6a of the 
priority list to output the request from the device having the highest priority. This will be request PRq. The second 
register 6b of the priority list 2 will control the output of the second multiplexer 1 0b to output the request with the second 
highest priority PR^. Likewise; the third register 6c controls the third multiplexer 10c to output the request with the third 

IS highest priority PRg and the fourth register 6d controls the fourth multiplexer 10d to output the request PR3 from the 
device with the lowest priority. The lowest priority multiplexer 10d can be omitted as a fixed priority input and instead 
the contents of the fourth register can be the default register 

[0059] An arbiter 12 is arranged to arbitrate between the various requests. The device having the highest priority 
which makes a request wins the arbitration. The priority arbiter provides a two bit output indicating which position in 
20 ihe priority list has won (index W), This is used to control a fifth multiplexer 14. The fifth multiplexer 14 receives an 
input from each of the four registers 6a to 6d of the priority list The fifth multiplexer 14 is controlled to output the identity 
of the device which has won the arbitration. The output of the fifth multiplexer is used to control a sixth multiplexer 16 
and a seventh multiplexer 18. 

[0060] The sixth multiplexer 16 is connected to each of the four registers 8 of the relegation list. The output of the 
2S f jfih multiplexer 1 4 controls the sixth multiplexer 1 6 to output the relegation value for the device winning the arbitration 
i.e. value RV^nw- 

[0061] The output of the fifth multiplexer 14 is also used to control the output of the seventh multiplexer 18. The 
seventh multiplexer 1 8 receives the transactions from each of the four devices and outputs the transaction T^w asso- 
ciated with the device which has won the arbitration. The signals involved in the request may be one or more of the 
30 following examples: request, grant, valid, address, read data, write data, op code etc. These values are held until the 
request is granted, acknowledged or withdrawn. In some embodiments of the present invention, withdrawn requests'- 
may not be permitted. 

[0062] In a pipelined system with strict ordering of requests, the requester identity is stored in a FIFO so that any 
return data or transaction can be routed back to the correct requester In a system where the returned transactk5n itself- 

35 contains the information, the routing to the correct requester can be determined without the need for a FIFO. 

[0063] The winning requester identity is used to look up the relegation value, this being the output of the sixth mul- 
tiplexer 16. This relegation value Is used to determine the next state of the priority list, along with the position In the 
list that the winner has. All items further down the list than the winner will shift up one place. 
[0064] Reference Is now made to Figure 4 which shows an implementation for the priority list. 

40 [0065] An adder 20 receives the relegation value for the winner RV^nw ^^om the fifth multiplexer 16 and the priority 
W of the winner are added together producing an index nw with any overflow from a two bit result is changed to 3. In 
other words, the winner cannot be relegated to a position any lower than bottom. The three bit output from the adder 
20 is input to a clipper 22 which if the output of the adder is in a three bit format Is clipped to a two bit format with the 
value being 3 (i.e. 11). The output of the clipper 22 is input to a first 2 to 4 line decoder 24. 

45 [0066] The value w is also input directly to a second 2 to 4 line decoder 26. The first and second decoders each 
have an input to each of the registers 6a to 6d making up the priority list. Each register's logic tells the one below if it 
should shift up. This is done If its w select line (WS) from the second 2 to 4 line decoder 26 is high or if it is being told 
to shift by the register above It via signal SHn and it is not the new location of the winner, that is its NW select line 
(NWSn) from the first 2 to 4 line decoder 24 is high. 

50 [0067] The first register 6a has its SH line tied low as it cannot shift higher and the SH output of the last register 16 
is not used. This approach can be extended to a list of any depth. 

[0068] Consider the example where the register 6a currently has a value 01 register 6b has the value 11 , register 
6c has the value 10 and register 6d has the value 00. The device associated with register 6a has won the arbitration 
and has a relegation value of 2. The first register 6a receives the values contained In the second register 6b. The 
55 values contained in the third register 6c are moved into the second register 6b. The values from the first register are 
moved into the third register 6c and the fourth register is unchanged. 

[0069] This method can be used with a list of any depth and can also be used, with suitable modifications, with the 
second embodiment. 
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[0070] Within each register at index n in the priority list, the new value will be that of RNw if NWSn is active othenwlse 
the incoming shift value from below If SHn is active othenwise it stays the same. It is an error In the system if SH3 is 
high when RN3 is low so It can be eliminated to save space if required. Also, WS3 is not required as the SH4 signal 
Is Ignored. 

5 [0071 ] Embodiments of the present invention can be implemented in a direct memory access controller. Embodiments 
of the present invention described hereinbefore have been described In the context of an arrangement where four 
devices are requesting access to for example a memory. This same technique can be used to arbitrate between different 
channels or between different requests or indeed any type of requesters. Embodiments of the present Invention can 
be used to arbitrate between request for access to any resource, including a bus, a memory or the like. 

10 [0072] The arbiter embodying the present Invention can be used in any suitable application. One possible application 
will now be described. 

[0073] In the following description reference Is made to an exemplary embodiment In which an MPEG-2 transport 

stream Is demultiplexed In a programmable transport interface of a receiver in a digital set-top-box. 

[0074] Figure 5 Illustrates a portion of a transport stream 51 which Is composed of a series of N transport packets 

*5 52. Each transport packet 52 comprises a transport packet header 54 and a transport packet payload 56. The transport 
stream is a bit stream which carries in the transport packet payloads 56 information for recreating, for example, a 
number of different television programmes. The transport stream Is formed by source encoding the television pro- 
grammes. The transport stream Is then typically channel encoded for transmission (by satellite or cable) and channel 
decoded on its reception to reproduce the transport stream. The transport stream is then source decoded to recreate 

20 a selected one of the different television programmes. Each particular television programme requires three types of 
information (audio information, video information and tables of programme information) for Its recreation. Each transport 
packet 52 is preferably associated with a particular television programme, a partk^ular source encoding time and a 
particular one of the information types. The individual transport packets are time division multiplexed to form the trans- 
port stream and allow the real-time recreation of any one of the different television programmes from the transport 

25 stream. To recreate a television programme the transport stream is sequentially demultiplexed to recover only the 
transport payloads 56 of audio information, video infornnation and tables of programme Information which are associ- 
ated with the selected television programme. The recovered payloads are then decoded and used to recreate the 
television programme. 

[0075] According to the MPEG-2 digital video broadcast (DVB) standard each of the transport packets 52 is 188 
30 bytes long and the transport packet header 54 is 4 bytes long The transport packet payload 56 contains either audio 
or video information or sections. The sections are parts of tables. The audio and video information and the sections in 
the payloads 56 are packetised and encoded in accordance with the (^PEG-2 DVB compression standard. 
[0076] A programmable transport interface 110, illustrated in Figure 6. is used to process a transport stream 51 and 
produce a data output stream 506 suitable for reconstitution as a television programme after MPEG-2 decoding by 
35 MPEG-2 decoders (not shown). The programmable transport interface 110 is included in a receiver which receives the 
transport stream 51. 

[0077] The transport packet header 54 contains a synchronisation byte which identifies the beginning of each trans- 
port packet 52. The transport packet header also contains a packet identification (PID) whkih identifies the Information 
type and the television programme associated with the transport packet payload 56. The transport packet 52 also 
40 contains information Identifying the source encoding time of the transport packet. The transport packet header 54, 
including the synchronisation byte and the PID, is not scrambled. The transport packet payload 56 nnay be scrambled. 
[0078] The programmable transport interface (PTI) 110 performs various functions Including: 



45 



SO 



i) using the synchronisation byte to identify the start of a transport packet 52; 

ii) using the packet identification (PID) to identify, amongst other functions, the type of information contained in the 
packet (i.e. audb or video information or sections) and the television programme it represents; 

iii) descrambling the transport packet payloads 56; and 

iv) demultiplexing the transport stream 51 to produce a data output stream 506. 



[0079] The data output stream 506 comprises a stream of audio information associated with the selected television 
programme, a stream of video information associated with the selected television programme, or tables of programme 
ss information associated with the selected television programme. The PTI outputs these streams to the necessary MPEG- 
2 decoders to reproduce the selected television programme. 

[0080] The programmable transport interface 110 comprises five primary functional blocks: an input module 100; a 
transport controller 200; an instruction SRAM (static RAM) 300; a data SRAM (static RAM) 400; and a multi-channel 
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DMA (direct memory access) controller 500. 

[0081] The input module 100 receives the transport stream 51 , and outputs an alternative output stream 106. The 
input module 100 identifies the synchronisation byte o1 each transport packet which is used to synchronise the system 
clock and the transport stream. The input module 100 is controlled by the transport controller 200 via an Input module 

s control signal 1 1 2 which includes a descrambling control signal 1 1 4, an alternative stream control signal 1 1 6 and output 
stream control signals 118. The input module 100 provides bits to the transport controller 200 via an interconnect 108 
and it receives bits back from the transport controller 200 via the interconnect 110. The input module, under the control 
of the transport controller 200 via the input module control signal 1 1 2, descrambles the pay load 56 of selected transport 
packets 52 and supplies the selected descrambled payloads to the transport controller 200 via the interconnect 108. 

10 The descrambling of the payloads Is controlled by the descrambling control signal 114 supplied by the transport con- 
troller 200 and the number and rate of bits supplied on the interconnect 108 is controlled by the output stream control 
signal 118. The input module 100 receives, along the interconnect 110, bits from the transport controller 200 which 
may be output as the alternative output stream 106 under the control of the alternative stream control signal 116. 
[0082] The transport controller 200 operates on the bits received on interconnect 108 from the input module 100. 

IS The transport controller 200 receives from the Input module 100 via interconnect 108 the transport packet header 54 
of the transport packet 52 arriving at the transport stream input interface 102. The transport controller 200 uses the 
packet identifier (PID) in the transport packet header 54 to determine whether the transport packet 52 now entering 
the input module 1 00 is associated with a selected television programme for the programmable transport interface 110. 
If it is not. the received transport packet 52 is discarded. If it is, it controls the input module 100 to descramble (if 

20 necessary) the transport packet payload (as described above), and to supply the transport packet paybad 56 via the 
interconnect 108 to the transport controller 200. The transport controller 200 may pass a payload 56 associated with 
audio or video information for the selected programme straight to the transport controller output 502. If the payload 56 
relates to a section of a table the transport controller 200 may process the information before providing it at its output 
502. Alternatively the transport controller 200 may process the received payloads 56 and repacketise them in accord- 

25 ance with a different transmission standard. The refomnatted transport stream is then provided to the input module 1 00 , 
via the interconnect 110 and it is output as the alternative output stream 106 under the control of the alternative strearn 
control signal 116. %^ 
[0083] The transport controller 200 comprises a transport processor (not shown) which reads instruction sets from 
the instruction SRAM 300.- The transport controller 200 is connected to the SRAM 300 by interconnect 304 and it. 

30 reads its instructions via the interconnect 304. A system processor (not shown) may read and write to the instruction 
SRAM 300 via a system interface bus 402. However, the transport controller 200 has preferential access to the instruc-^ . 
tion SRAM 300 determined by an arbiter (not shown) which arbitrates between accesses by the transport controller, 
200 and the system processor. The system processor may also access the transport controller 200 via the system , 
interface bus 402. 

35 [0084] The data SRAM 400 can be accessed by the processor of the transport controller 200 via the interconnections 
404 and 406, The processor of the transport controller uses the interconnection 404 to read from and write to the data' 
SRAM 400. A search engine within the transport controller 200 reads from the data SRAM 400 along interconnection 
406. The search engine searches the data SRAM 400 for the packet identifier (PID) in the incoming transport packet 
header 104. If the packet is not to be discarded, then the PID for that packet will have been stored in the data SRAM, 

40 and is located by the search engine of the transport controller Associated with each PID in the data SRAM is a plurality 
of pointers, which point to other addresses in the data SRAM where other Information associated with the incoming 
transport packet is stored. The search engine retrieves the pointers stored with a particular PID for use by the transport 
controller processor. The transport controller processor then uses the pointers to access all the information it needs 
to process the payload of the incoming transport packet. The pointers may, for example: point to descrambling keys 

45 for use by the input module 100; point to addresses for use by the DMA controller 500; identify whether the payload 
is video or audio information or sections, identify whether the payload is special data to be output on alternative output 
stream 1 06; or locate information for masking the search filter etc. 

[0085] Thus, this infornnation enables the transport controller to generate the input module control signals 112 as 
appropriate, and control the processing, if any, of the bits received on interconnect 108. 
so The transport controller 200 produces a transport controller output 502 which is supplied to the multi-channel DMA 
controller 500 The multi-channel DMA controller 500 supplies the data output stream 506^ indirectly, to the MPEG-2 
decoders (not shown in Figure 6). 

[0086] The system processor writes to each of the instruction SRAM 300, the transport controller 200 and the data 
SRAM 400 via the system interface bus 402. The instruction SRAM 300 can only be written to by the system processor; 
ss the transport controller can only read from, and not write to, Its own instruction SRAM 300 via the Interface 304. The 
system processor can also read from the instruction SRAM. An arbiter (such as described hereinbefore) Is provided 
to arbitrate between accesses to the instructions SRAM 300 by both the system processor and the transport controller 
200. 
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[0087] The system processor, via the system interface bus 402. and the transport controller 200 via Interface bus 
404. can both read and write to the data SRAM 400. The search engine of the transport controller 200 can only read 
from the data SRAM 400 via interface bus 406. The arbiter is provided to arbitrate accesses to the data SRAM 400 by 
each of the system processor, the transport controller 200, and the search engine within the transport controller 200. 
s The transport controller nnay be reset by the system processor by a reset signal on the interface bus 302. 

[0088] The system processor, via system interconnect bus 402, and the transport controller 200 via the bus 404, can 
both read and write to registers within the DMA controller 500. The arbiter is provided to arbitrate between the system 
processor and transport controller access to the DMA controller. 

[0089] The system processor via system interface 402 also accesses registers within the transport controller 200, 
10 to read and write thereto. 

[0090] The system processor initially writes to the instruction SRAM 300, the data SRAM 400, and registers within 
the transport controller 200 and the DMA controller 500, to configure them. 

[0091 ] The DMA controller 500 of the programmable transport interface 1 0 of Figure 6 controls the input into memory 
of demultiplexed data on lines 502 from the transport controller 200. The output 506 of the DMA controller 500 outputs, 
IS as will be described in further detail hereinafter, data demultiplexed by the transport controller 200 into appropriate 
areas of the main processor memory. 

[0092] Referring now to Figure 7. there is shown In more detail the interconnection of the DMA controller 500 with 
the transport controller 200, a main processor 700, a main memory 702, a first MPEG decoder 704. a second MPEG 
decoder 706, a third MPEG decoder 708 and an arbiter 71 0. The arbiter 7 1 0 is not shown In Figure 6 for clarity purposes, 

20 but in fact arbitrates between accesses to the DMA controller 500 via the system interconnect bus 402 and the transport 
controller interconnect bus 404. Thus the arbiter 710 receive the transport controller interconnect bus 404 from the 
transport controller 200 and the main processor interconnect bus 402 from the main processor 700. The arbiter 710 
then provides access to the DMA controller 500 for the one of the transport controller 200 and the main processor 700 
which is chosen to have control of the DMA controller 500. The arbiter 710 generates an arbiter request signal ARBREQ 

2S on line 7 1 2 to the DMA controller 500, receives an arbiter grant signal ARBGRANT on line 71 4 from the DMA controller 
500, generates an arbiter address ARBADD on lines 716 to the DMA controller 500, generates arbiter input data 
ARBDATAINI on line 718 to the DMA controller, receives arbiter output data ARBDATAOUT on line 720 from the DMA 
controller, and generates an arbiter read/write signal ARBR/W on line 720 to the DMA controller 500. 
[0093] The transport controller 200 outputs the data to be transferred to processor memory 702 to the DMA controller 

30 500 via output lines 502. As shown in Figure 7 the output lines 502 include a set of data lines DATA 724, a transport 
controller request signal TCREQ on line 726 output by the transport controller 200 to the DMA controller 500 and a 
transport controller grant signal TCGRANT on line 728 output from the DMA controller 500 to the transport controller 
200. 

[0094] The memory which the DMA controller 500 outputs data to for storage is the main system memory 702. and 
35 therefore the output of the DMA controller 500 shown in Figure 6 is, in this preferred implementation of the invention, 
the system interconnect bus 402. Thus in Figure 7 the DMA controller 500 Is shown outputting data onto the main 
system interconnect bus 402 rather than to the output signals 506. 

[0095] The main system interconnect bus 402 between the DMA controller 500 and main memory 702 includes a 
DMA read/write signal DMAR/W on line 730 from the DMA controller 500 to the main memory 702, DMA data output 

40 . signals DMADATAOUT on lines 732 from the DMA controller 500 to the main memory 702, a DMA request signal 
DMAREQ on line 738 from the DMA controller 500 to the main memory 702, a DMA grant signal DMAGRANT on line 
736 from the main memory 702 to the DMA controller 500, a DMA valid signal DMAVALID on line 734 from the main 
memory 702 to the DMA controller 500, DMA input data DMADATAIN on lines 740 from the main menrrary 702 to the 
DMA controller 500. and a DMA address signal DMAADD on lines 742 from the DMA controller 500 to the main memory 

45 702. 

[0096] In alternative embodiments of the present invention, the arbiter embodying the present invention can be used 
to arbitrate between requests from different direct memory access channels. 

[0097] In some embodiments of the present invention, a set of rules may be adopted to prevent a device from being 

starved of access. For example, at least two of the requesters may have a relegation value equal to the length of the 
so list. No more than one of the devices should have a relegation value of 1 . Finally, no device should have a relegation 
value of 0. 



Claims 

55 

1. An arbiter for arbitrating between a plurality of requests from a plurality of requesters, said arbiter being arranged 
to assign an order of priority of said requesters, the requester having the highest priority and which has made a 
request winning the ariDitration, wherein the arbiter determines a new priority for said winning requester, said winner 
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being given a priority different from the lowest priority. 

An arbiter as claimed in claim 1. wherein the arbiter Is a arranged to assign relegation information to each of said 
requesters, the relegation information determining the priority of a winner of said arbitration after the winner has 
won an arbitration. 

An arbiter as claimed in claim 2, wherein the relegation Information can be changed during use of said arbiter. 

An arbiter as claimed in any preceding claim, wherein said arbiter has a list of requesters, the list defining the 
priority of said requesters, wherein said list Is arranged to include at least one requester in at least two different 
positions in said list. 

An arbiter as claimed In claim 4, wherein said list is longer than the number of requesters. 

An arbiter for arbitrating between a requests from a plurality of requesters, said arbiter being arranged to assign 
an order of priority to said requesters and relegation information to each of said requesters, the relegation infor- 
mation determining the priority of a winner of said arbitration after the winner has won an arbitration. 

An arbiter for arbitrating between a plurality of requests from a plurality of requesters, said arbiter having a list of 
requesters, at least some of said requesters making requests, the list defining the priority of said requesters, 
wheiein said list is arranged to include at least one requester in at least two different positions In said list. 

An arbiter as claimed In claim 7, wherein the winner of the arbitration performed by said arbiter Is at the end of the 
list for the next arbitration. 

An arbiter for arbitrating between a plurality of requests from a plurality of requesters, said arbiter assigning a 
priority to each of said requesters, the priority assigned to each requester determining the frequency with which 
each requester wins an arbitration, wherein said arbiter is configurable to provide to the required priority for each^ 
requester 

10. An arbiter as claimed In claim 9. wherein said arbiter is configured prior to use. 

11. An arbiter as claimed in claim 9 or 10, wherein said the configuration of said arbiter is alterable during use. 

35 12. An arbiter as claimed In any preceding claim for ariDitrating between requests from requesters requesting access 
to a memory. 

13. An arbiter as claimed in any preceding claim, wherein said requester comprises a device. 

40 14. An arbiter as claimed In any preceding claim, wherein said requester comprises a channel. 

1 5. An arbiteras claimed in any preceding claim, wherein said arbiter is arranged to consider only some of the request- 
ers when arbitrating between said requesters, said considered requesters having the highest priority. 

45 16. An Integrated circuit comprising an arbiter as claimed in any preceding claim. 

17. A method of arbitrating between a plurality of requests from a plurality of requesters, said method comprising 
assigning an order of priority to the requesters, determining which requester has the highest priority and which 
has made a request, said requester winning the arbitration, determining a new priority for the winning requester, 
so the new priority being different from the lowest priority 
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